提高安全性的最佳 Nginx 配置

由于安全问题一直是重中之重，这里整理下 nginx 的安全配置。文章大部分参考了 Best nginx configuration for improved security(and performance). 及 Jerry Qu，更多关于 HTTP 安全及性能可前往 Jerry Qu 查看。

server_tokens

该响应头用于禁止 nginx 在响应中报文中包含版本信息。因为具体的版本可能会存在未知 bug。

server_tokens off;

X-Frame-Options

该响应头用于是否允许浏览器加载 frame、 iframe、 object 等属性。可以使用该功能来避免 点击劫持

add_header X-Frame-Options SAMEORIGIN;

该指令用三个可用的配置

• X-Frame-Options: DENY
• X-Frame-Options: SAMEORIGIN
• X-Frame-Options: ALLOW-FROM https://example.com/

当设置为 DENY 时，站点禁止任何页面被嵌入。

当设置为 SAMEORIGIN 时，只允许加载同源的 fram/iframe/object。

当设置为 ALLOW-FROM 时，只允许加载指定的源。

X-Content-Type-Options

在我们通常的请求响应中，浏览器会根据 HTTP 响应的 Content-Type 来分辨响应的类型。如 text/html 代表 html 文档。 但当响应类型未指定或错误指定时，浏览会尝试启用 MIME-sniffing 来猜测资源的响应类型。

如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的 HTML 和 JavaScript 代码。由于未关闭资源的类型猜测，浏览器将直接执行嵌入的 JavaScript 代码，而不是显示图片。

add_header X-Content-Type-Options nosniff;

用来指定浏览器对未指定或错误指定 Content-Type 资源真正类型的猜测行为，nosniff 表示不允许任何猜测。（Jerry Qu）

这个响应头的值只能是 nosniff，可用于 IE8+ 和 Chrome。

X-XSS-Protection

add_header X-XSS-Protection "1; mode=block";

该响应头是用于防范及过滤 XSS 的。可用的几个指令如下：

• X-XSS-Protection: 0
• X-XSS-Protection: 1
• X-XSS-Protection: 1; mode=block
• X-XSS-Protection: 1; report=<reporting-uri>

说明

• 0，禁用 XSS 过滤
• 1，开启 XSS 过滤
• 1; mode=block，开启 XSS 过滤，并且若检查到 XSS 攻击，停止渲染页面。
• X-XSS-Protection: 1; report=<reporting-uri>，开启 XSS 过滤，并且若检查到 XSS 攻击，将使用指导的 url 来发送报告。

Content-Security-Policy

该响应头主要用于规定页面可以加载那些资源（css/js/img 等）。看一个简单的配置

# 定义所有资源文件的默认加载规则为self，表示允许
# 相同来源的内容（相同的协议、域名和端口）
add_header Content-Security-Policy: default-src 'self';

更多 Content-Security-Policy 的指令及规则及介绍可参考 Jerry Qu 的 Content Security Policy 介绍。

Strict-Transport-Security

Strict-Transport-Security，简称 HSTS。该响应头用于标识浏览器用 HTTPS 替代 HTTP 的方式去访问目标站点。

我们知道 HTTPS 相对于 HTTP 有更好的安全性，而很多 HTTPS 网站，也可以通过 HTTP 来访问。开发人员的失误或者用户主动输入地址，都有可能导致用户以 HTTP 访问网站，降低了安全性。一般，我们会通过 Web Server 发送 301/302 重定向来解决这个问题。 （Jerry Qu）

我们可以使用下面方式启用 HSTH。

add_header strict-transport-security: max-age=16070400; includeSubDomains;

当用户第一次访问后，将返回一个包含了 strict-transport-security 响应头的字段。他将告诉浏览器，在接下来的 16070400 秒内，当前网站的所有请求都强制使用 HTTPS 的方式访问。即使用户手动输入 http://，浏览器也会强制使用 HTTPS 方式访问。

参数 includeSubDomains 是可选的，当指定了该参数，所有子域名将采用同样的 HSTS 规则。

可以看到 HSTS 可以很好的解决 HTTPS 降级攻击，但是对于 HSTS 生效前的首次 HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了 HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用 HTTPS 协议。 （Jerry Qu）

如果你想把自己的域名加入这个列表，可通过 hstspreloa.org 查看是否满足申请条件。更多关于 HSTS 的配置，可查看 关于启用 HTTPS 的一些经验分享。

目前 godruoyi.com 已成功加入 Preload List。